fix: respect connectTimeoutMs when waiting for first top-level page#2010
Closed
octo-patch wants to merge 1 commit intobrowserbase:mainfrom
Closed
fix: respect connectTimeoutMs when waiting for first top-level page#2010octo-patch wants to merge 1 commit intobrowserbase:mainfrom
octo-patch wants to merge 1 commit intobrowserbase:mainfrom
Conversation
…ixes browserbase#1287) On slow machines Chrome may still be setting up the first page after the CDP WebSocket handshake completes. The previous code always used a fixed 5-second timeout (DEFAULT_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MS) regardless of any user-supplied timeout. Now V3Context.create() takes the *maximum* of connectTimeoutMs and the env-var/CI-derived default, so users who already bump connectTimeoutMs for a slow environment automatically get the same patience when waiting for the first page to appear—without any new API.
|
Contributor
|
This PR is from an external contributor and must be approved by a stagehand team member with write access before CI can run. |
github-actions
Bot
added
external-contributor
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
pirate
approved these changes
Apr 21, 2026
github-actions
Bot
added
external-contributor:mirrored
Contributor
pirate
added a commit
that referenced
this pull request
Apr 22, 2026
…top-level page (#2025) Mirrored from external contributor PR #2010 after approval by @pirate. Original author: @octo-patch Original PR: #2010 Approved source head SHA: `fd9ed12d2499c022b45ba30703c75082dc743a78` @octo-patch, please continue any follow-up discussion on this mirrored PR. When the external PR gets new commits, this same internal PR will be marked stale until the latest external commit is approved and refreshed here. ## Original description Fixes #1287 ## Problem On slow machines, Chrome may still be setting up the first tab by the time the CDP WebSocket handshake completes. `V3Context.create()` previously waited a fixed 5 seconds (`DEFAULT_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MS`) for the first top-level page to register, regardless of any user-supplied timeout, causing a `TimeoutError: waitForFirstTopLevelPage (no top-level Page) timed out after 5000ms` on slow hardware. ## Solution Take the *maximum* of `localBrowserLaunchOptions.connectTimeoutMs` and the existing env-var / CI-derived default. This means users who already bump `connectTimeoutMs` to accommodate a slow environment automatically get the same patience when waiting for the initial page—no new API surface needed. ```ts // Before await ctx.ensureFirstTopLevelPage(getFirstTopLevelPageTimeoutMs()); // After const firstPageTimeoutMs = Math.max( opts?.localBrowserLaunchOptions?.connectTimeoutMs ?? 0, getFirstTopLevelPageTimeoutMs(), ); await ctx.ensureFirstTopLevelPage(firstPageTimeoutMs); ``` Existing escape hatches (`STAGEHAND_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MS` env var, `CI` auto-bump to 30 s) are unchanged—this change only applies a floor when the user has explicitly set a higher `connectTimeoutMs`. ## Testing - Existing unit and integration tests continue to pass (no change to default behaviour). - Users on slow machines / WSL2 can now set `connectTimeoutMs: 30000` in `localBrowserLaunchOptions` and the first-page wait will scale with it. <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Respect `connectTimeoutMs` when waiting for the first top‑level page to avoid startup timeouts on slow machines. Fixes #1287. - **Bug Fixes** - `V3Context.create()` now waits up to `max(localBrowserLaunchOptions.connectTimeoutMs, getFirstTopLevelPageTimeoutMs())` for the first page. - Keeps `STAGEHAND_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MS` and CI defaults unchanged; no API changes. <sup>Written for commit 0998c75. Summary will update on new commits. <a href="https://cubic.dev/pr/browserbase/stagehand/pull/2025">Review in cubic</a></sup> <!-- End of auto-generated description by cubic. --> <!-- external-contributor-pr:owned source-pr=2010 source-sha=fd9ed12d2499c022b45ba30703c75082dc743a78 claimer=pirate --> --------- Co-authored-by: octo-patch <octo-patch@users.noreply.github.com> Co-authored-by: Nick Sweeting <git@sweeting.me>
github-actions
Bot
added
external-contributor:completed
Contributor
|
The mirrored PR #2025 has been merged into |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1287
Problem
On slow machines, Chrome may still be setting up the first tab by the time
the CDP WebSocket handshake completes.
V3Context.create()previouslywaited a fixed 5 seconds (
DEFAULT_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MS) forthe first top-level page to register, regardless of any user-supplied
timeout, causing a
TimeoutError: waitForFirstTopLevelPage (no top-level Page) timed out after 5000mson slow hardware.Solution
Take the maximum of
localBrowserLaunchOptions.connectTimeoutMsand theexisting env-var / CI-derived default. This means users who already bump
connectTimeoutMsto accommodate a slow environment automatically get thesame patience when waiting for the initial page—no new API surface needed.
Existing escape hatches (
STAGEHAND_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MSenvvar,
CIauto-bump to 30 s) are unchanged—this change only applies afloor when the user has explicitly set a higher
connectTimeoutMs.Testing
connectTimeoutMs: 30000inlocalBrowserLaunchOptionsand the first-page wait will scale with it.Summary by cubic
Respect
connectTimeoutMswhen waiting for the first top‑level page to avoid startup timeouts on slow machines. Fixes #1287.V3Context.create()now waits up tomax(localBrowserLaunchOptions.connectTimeoutMs, getFirstTopLevelPageTimeoutMs())for the first page.STAGEHAND_FIRST_TOP_LEVEL_PAGE_TIMEOUT_MSand CI defaults unchanged; no API changes.Written for commit fd9ed12. Summary will update on new commits. Review in cubic